前言
在 Day 1 中，我們回顧了傳統 HIS 系統中點對點串接（Point-to-Point）與 HL7 v2 格式所帶來的維護瓶頸。今天，我們正式切入次世代醫療資訊交換標準的核心——HL7 FHIR（Fast Healthcare Interoperability Resources）。對於具備現代 Web 開發經驗的工程師來說，FHIR 的學習曲線遠比 HL7 v2 或 v3 平緩得多。因為 FHIR 並不是重新發明輪子，而是將全球網際網路行之有效的標準——REST、HTTP、JSON/XML、OAuth2——完整引入醫療領域。本篇將帶你深入剖析 FHIR 的四大支柱架構，並拆解最核心的概念：Resource（資源） 的組成語意與 JSON 結構規範。

一、FHIR 的核心設計理念：
80/20 法則傳統醫療資料標準（如 HL7 v3）常犯的一個錯誤，是試圖在一套規範中定義「全世界所有醫療情境的所有欄位」，導致規格書動輒數千頁，實作門檻極高。FHIR 採取了務實的 「80/20 法則」：核心規範（Core Resources）： 官方 Resource 僅收錄全球醫療系統中 80% 場景都會用到的通用欄位（例如病人的姓名、出生日期、性別）。擴充機制（Extensions）： 剩下的 20% 屬於特定國家、法規或專科的特殊欄位（例如臺灣的身分證字號、原住民註記、健保卡就醫序號），則透過標準化的 Extension 機制延伸，而不會污染核心結構。

二、什麼是 Resource？
在 FHIR 的世界裡，所有醫療概念都被塑模為一個個獨立的 Resource。截至 FHIR R4 / R5，官方定義了超過 140 種 Resources，通常依業務層級分為以下幾大維度：
Plaintext
FHIR Resource 分類:

每個 Resource 都是一個自給自足的資料單元，具備唯一的識別碼（Logical ID），並且可以透過 URL 與其他 Resource 互相引用（Reference）。

三、剖析標準 Resource 的 JSON 結構
一個標準的 FHIR Resource（以 JSON 格式表示）主要由以下四大部分組成：
resourceType：宣告這個物件屬於哪一種 Resource（必填，字串）。id：該資源在 FHIR Server 上的唯一識別碼。meta：中繼資料，記錄版本號（versionId）、最後更新時間（lastUpdated）以及所遵循的規範設定（profile）。text（Narrative）：人類可讀的 HTML 區塊，確保即使客戶端無法解析深層 JSON，臨床人員依然能透過網頁看懂這筆資料的摘要。商業資料欄位（Elements）：如 identifier、name、gender 等具體臨床資料。
標準 Patient Resource 範例

四、FHIR 資料型態的基石：
Coding 與 CodeableConcept在一般開發中，我們可能直接存入 "gender": "male" 或 "status": "completed"。但在跨國跨院的醫療情境中，文字可能產生歧義，因此 FHIR 大量使用 Coding 與 CodeableConcept。
1. Coding（編碼）精確對應到某一個編碼標準（Code System）上的代碼。包含三個核心屬性：system：編碼系統的命名空間 URI（例如 LOINC、SNOMED CT、ICD-10）。code：具體代碼符號。display：代碼的人類可讀說明。
2. CodeableConcept（概念編碼）代表臨床上的某個概念。因為同一個臨床概念可能在不同系統有不同的代碼（例如同時具備健保代碼與國際 SNOMED 代碼），所以一個 CodeableConcept 內部可以包含一個陣列的 coding[]，並提供一個文字描述 text：

五、FHIR 的 RESTful 操作語意FHIR 將 HTTP 動詞標準化為臨床行為：

小結
今天我們建立了 FHIR 的核心概念認知：
1.掌握了 80/20 法則 與核心 Resource 分類。
2.理解了 Resource 的四大基礎結構：resourceType、meta、text 與業務 Elements。
3.認識了確保醫療語意一致性的 Coding 與 CodeableConcept 機制。理解了這些規範後，

明天 Day 3 我們將聚焦在臨床流程的第一線：深入解析 Patient 與 Practitioner Resource，看看在臺灣真實醫療場域中，病患身分證、居留證、病歷號與護理人員識別碼該如何對應！